昨天，我們決定打造一位 AI 上線守門員。今天要先定義它的工作。
假設我們完成一個訂餐網站。使用者可以登入、選擇餐點並送出訂單。開發者在自己的電腦測試三次，三次都成功。這個網站可以上線了嗎？
現在還不能下結論。
我們不知道同時有一百人下單時會發生什麼事，也不知道付款服務逾時後會不會重複建立訂單。如果資料庫故障，我們甚至不知道團隊會在多久後發現。
功能測試只能證明正常流程可以完成。Production Readiness 要回答另一個問題：
系統遇到真實流量、錯誤輸入、外部故障與人為失誤時，團隊能不能控制風險？
Production Ready 不是一張通用證書
Production Ready 沒有適用所有產品的固定標準。個人作品、醫療系統和支付服務承擔的風險不同，因此需要不同的保護措施。
Google SRE 使用 Production Readiness Review，簡稱 PRR，檢查服務是否符合正式環境的操作與可靠性要求。審查範圍包含系統架構、服務依賴、監控、緊急應變、容量、變更管理及效能。
PRR 的重點不是追求完美。團隊需要找出最可能傷害使用者或中斷服務的問題，排定修正順序，並留下可以驗證的證據。
Production Ready 代表團隊已經理解主要風險，建立必要的防護，並準備好在故障發生時偵測、處理與復原。
上線前要回答的七個問題
一、系統壞掉時，使用者會失去什麼？
團隊要先找出系統最重要的功能。訂餐網站的首頁圖片載入失敗，影響通常有限。訂單重複扣款，影響就很嚴重。
我們不能把所有錯誤視為同一個等級。團隊應先保護會造成金錢損失、資料外洩或核心功能中斷的流程。
二、外部依賴失敗時，系統會怎麼反應？
現代產品會依賴資料庫、身分驗證、付款、電子郵件與第三方 API。任何一項服務都可能變慢或停止回應。
系統至少要設定 Timeout，避免請求無限等待。Retry 也要限制次數，否則大量重試可能讓故障更加嚴重。核心依賴失效時，產品還需要決定要停止服務、提供降級功能，還是暫存請求。
三、未授權的人能不能取得資料或執行操作？
登入只能證明使用者是誰，不能證明使用者有權讀取每一筆資料。後端 API 必須檢查資源擁有者與角色權限。例子：使用者登入後，把網址中的訂單 ID 從 1001 改成 1002。如果 API 直接回傳另一位使用者的訂單，系統就存在越權問題。
團隊也要檢查日誌、錯誤訊息和管理後台。這些地方常在無意間暴露電子郵件、Token 或其他個人資料。
四、團隊看得見故障嗎？
系統回傳錯誤，不代表團隊知道錯誤正在發生。服務需要記錄足以排查問題的 Log，也需要衡量請求量、錯誤率與延遲。
告警必須指向使用者受到的影響。CPU 短暫升高不一定需要叫醒工程師；結帳失敗率持續上升則需要立即處理。
五、流量增加時，系統能撐多久？
容量規劃不只估算伺服器數量。團隊還要確認資料庫連線、API 配額、記憶體與第三方服務限制。
如果系統沒有測過負載，我們就不能只憑開發環境的速度判斷正式環境的表現。
六、部署失敗時，團隊能安全回復嗎？
每次部署都可能帶入錯誤。團隊需要知道如何停止發布、回滾程式，以及處理不能直接回滾的資料庫變更。
「我們以前沒有部署失敗」不是證據。一次成功的回滾演練，比一份沒有執行過的文件更可靠。
七、事故發生時，誰負責處理？
監控找到問題後，仍需要有人判斷影響、執行修復並通知相關人員。小型專案也應留下基本操作說明，例如如何查看錯誤、停用有問題的功能，以及從備份復原資料。
如果只有原作者知道系統如何運作，原作者本身就是單點故障。
不要只問「有沒有」，還要查看證據
審查結果不需要只有「通過」和「失敗」。我們可以使用三種狀態：
我們的第一版檢查範圍
這個系列會先檢查七個面向：
明天，我們會從零規劃 Demo 專案。我們也會決定要刻意放入哪些問題，讓未來的 Agent 有一個可以重複測試的靶場。
參考資料
iThome鐵人賽
看影片追技術